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Abstract 

A  state-based  approach  is  presented  for  specification  of  real-time  software  at  multiple  levels  of 
abstraction.  In  this  approach,  specification  at  each  level  is  performed  in  terms  of  a  Hierarchical 
Multi-State  (HMS)  machine,  with  the  higher  levels  defining  requirements  and  the  lower  levels 
indicating  methods  of  achieving  the  requirements.  This  leads  to  a  considerable  simplification  of 
the  specification  process,  can  lead  to  reusability  of  specifications  and  is  fundamentally  different 
from  the  refinement  approach  to  specification.  A  restricted  method  of  verifying  the  consistency 
of  multi-level  specifications  is  also  presented.  By  the  use  of  this  method,  necessary  scheduling  of 
concurrent  tasks  to  satisfy  a  complex  set  of  logical  and  temporal  constraints  can  be  derived.  ' 

( 

Keywords:  Formal  specification,  verification,  state  models,  real-time  systems,  requirements 
specification,  real-time  scheduling,  automata,  HMS  machines. 

1.  Introduction 

Three  critical  problems  in  the  early  phases  of  the  life-cycle  of  real-time  software  are:  (1) 
definition  of  requirements,  (2)  specification  of  the  system  at  a  conceptual  level  prior  to 
software  design,  and  (3)  verification  that  the  requirements  are  satisfied  by  the  specification. 
The  objectives  of  this  paper  are  to  present  a  state-based  specification  method  for  real-time 
software,  in  which, 

o  Specification  is  performed  in  terms  of  nondeterministic  abstract  machines  that 
represent  the  generic  behavior  of  entire  classes  of  software. 

0  Requirements  are  stated  as  higher-level  abstract  machines  that  define  the  desir¬ 
able  behaviors  of  the  nondeterministic  lower-level  specifications. 

o  Formal  techniques  can  be  applied  to  verify  whether  a  specification  can  be  ex¬ 
ecuted  in  such  a  manner  that  the  requirements  are  satisfied. 

The  notion  of  multi-level  specification  presented  in  this  paper  is  fundamentally  different 
from  the  “refinement”  approach  to  hierarchical  specification.  In  the  latter  approach,  typi¬ 
fied  by  [Ab-88]  and  common  to  the  computer  security  field  (see.  e.g.,  [Ch-81]),  one  usually 
begins  with  a  top-level  specification.  Thereafter,  one  creates  successively  lower-level  inde¬ 
pendent  specifications  that  are  proven  to  be  consistent  with  higher  levels.  At  the  end  of  this 
process,  the  lowest  level  stands  alone  as  the  final  specification.  In  contrast,  in  our  approach, 
each  higher-level  specification  imposes  constraints  lower-level  specifications  such  that 
all  levels  reT.aiii  part  cf  the  final  specitication.  Moreover,  each  level  can  be  reused  in  other 
contexts. 


The  work  reported  in  this  paper  was  supported  in  part  by  the  Office  of  Naval  Research  under 
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Numerous  techniques  have  been  proposed  in  the  literature  for  specification  of  real-time 
software  (see,  e.g.,  some  of  the  papers  in  [Ge-86]  and  [St-88]).  The  approach  presented 
here  is  an  extension  of  the  Hierarchical  Multi-State  (HMS)  machine  specification  method 
presented  in  [Ga-88a],  [Ga-88b]  and  [Fr-89].  An  earlier  version  of  HMS  machines  was 
introduced  in  [Ga-87]  for  causal  modeling  of  dynamic  systems.  Intuitively,  HMS  machines 
are  high-level  automata,  in  which  multiple  states  can  be  active  at  any  moment  of  time, 
multiple  transitions  can  occur  simultaneously,  states  can  be  decomposed  hierarchically  into 
lower-level  machines,  and  there  exists  a  rich  language  for  representing  logical  and  temporal 
dependencies  among  states  and  transitions. 

The  benefits  of  using  the  HMS  machine  model  in  [Ga-88a]  for  the  specification  of  real-time 
systems  are  (1)  orders  of  magnitude  reduction  in  the  number  of  states  compared  to  finite- 
state  machines  and  similar  formalisms,  (2)  ability  to  represent  and  reason  about  concur¬ 
rency  and  hard  real-time  constraints,  (3)  executability,  and  (4)  formal  techniques  for  verify¬ 
ing  that  “safety  properties”  are  not  violated  [Fr-89]. 

The  HMS  machine  model  has  some  similarities  and  major  differences  with  a  number  of 
other  state-based  modeling  techniques  in  the  literature  such  as  Petri  nets  [Re-82],  State- 
charts  [Ha-87]  and  Modecharts  [Ja-88].  The  most  important  similarity  is  that  multiple 
states  may  be  true  or  “marked”  at  any  moment  of  time,  thereby  reducing  the  complexity  of 
the  state  space.  In  comparison  with  Petri  nets,  HMS  machines  provide  a  higher-level  lan¬ 
guage  that  avoids  the  need  for  intermediate  dummy  states  that  are  often  needed  to  maintain 
logical  consistency  in  Petri  nets.  Also,  while  the  semantics  of  Petri  nets  makes  it  difficult  to 
distinguish  between  precedence  and  causality,  causal  relationships  are  easily  represented  in 
HMS  machines  [Ga-87].  In  comparison  with  Statecharts  and  Modecharts,  the  major  differ¬ 
ences  in  the  basic  models  are  in  the  form  of  controls  on  transitions,  the  language  of  time,  the 
rules  of  execution,  and  the  graphic  notation. 

The  purpose  of  this  paper  is  two-fold:  (1)  We  introduce  an  approach  for  constraining 
nondeterministic  HMS  specifications  in  terms  of  higher-level  HMS  “policy  machines”  that 
both  define  requirements  and  suggest  how  requirements  can  be  achieved.  For  a  software 
system,  a  lower-level  machine  can  represent  the  specification  of  a  “generic”  program, 
where,  besides  the  types  of  variables,  other  features  may  have  been  left  undefined.  This 
replaces  and  extends  the  prioritized  policy  method  of  [Ga-88a].  (2)  We  present  a  new 
method  for  verifying  that  certain  conditions  with  finite  temporal  bounds  are  achievable  in  a 
specification.  Specifically,  we  demonstrate  that  if  a  choice  of  actions  (such  as  calls  to  soft¬ 
ware  modules)  to  reach  a  goal  state  is  known,  then  one  can  derive  analytically  the  precise 
ordering  and  intermediate  delays  between  the  actions  that  are  necessary  to  meet  a  complex  set 
of  logical  and  temporal  constraints.  This  method  is  complementary  to  the  verification  meth¬ 
ods  of  [Fr-89],  where  correcfness-prc.serving  transformations  were  employed  lo  demon¬ 
strate  that  states  corresponding  to  undesirable  safety  conditions  are  unreachable. 

Section  2  of  this  paper  introduces  the  definition  of  basic  HMS  machines,  along  with  exam¬ 
ples  of  the  graphic  notation  for  representing  them.  Section  3  presents  our  approach  to  the 


use  of  higher-level  HMS  machines  to  constrain  lower-level  nondeterministic  HMS  ma¬ 
chines.  Section  4  introduces  our  method  of  verification  of  HMS  specifications  and  Section  5 
presents  an  example  demonstrating  the  utility  of  the  multi-level  specification  and  verifica¬ 
tion  methods.  The  summary  is  presented  in  Section  6. 

2.  Definition  of  HMS  Machines 

In  this  section,  we  present  the  basic  definitions  for  “HMS  machines,”  which  constitute  our 
state-based  specification  formalism  at  the  lowest  level  of  abstraction.  In  the  next  section, 
we  extend  slightly  the  definitions  and  present  an  approach  to  “multi-level”  specification, 
where  HMS  machines  at  different  levels  of  abstraction  interact  with  each  other. 

We  begin  by  introducing  a  language  for  representing  temporal  constraints.  Then,  we  define 
how  a  machine  is  constructed  in  terms  of  its  states  and  transitions  (which  are  controlled  by 
other  states).  Finally,  we  present  formally  how  changes  occur  in  a  machine  as  time  prog¬ 
resses. 

Definition  1  (Time  Expression):  t  is  a  “time  expression”  if  t  is  of  the  form  ^ti ,  t2>,  <ti ,  t2>!, 
or  [ti,  t2],  where  ti  and  t2  are  integers  and  ti  <  t2  <  0.  When  ti  =  t2  =  t,  these  three  time 
expressions  will  be  written  as  t,  t!,  and  t,  respectively. 

The  time  expressions  have  informal  names:  (1)  <ti,  t2>  is  called  a  “sometime-delay”  and 
represents  existential  quantification  of  time  over  the  period  from  ti  to  t2,  (2)  [ti,  t2]  is  called 
an  “always-delay”  and  represents  universal  quantification  of  time  for  the  period  from  ti  to 
t2,  and  (3)<ti,  t2>!  is  called  a  “sometime-change-delay.”  The  precise  interpretation  of  the 
different  time  expressions  will  be  presented  in  Definition  6. 

Definition  2  fControO:  c  is  a  “control”  over  a  set  of  “states”  S  if  x  is  a  time  expression  and  c 
is  (s,  r)  or  (-.s,  x),  for  some  state  s  e  S. 

Definition  3  (Transition):  7  is  a  “transition”  over  the  set  of  states  S  if  7  is  of  the  form 

id:  (PRIMARIES)  (CONTROLS)  — >  (CONSEQUENTS) 

where  id  is  a  “label,”  PRIMARIES  is  a  (possibly  empty)  subset  of  S,  CONTROLS  is  a  (possi¬ 
bly  empty)  set  of  controls  over  S,  and  CONSEQUENTS  is  a  (possibly  empty)  subset  of  S. 
These  three  sets  will  be  denoted  PRIMS(7),  CTRLS(7)  and  CNSQS(7),  respectively. 

We  will  now  introduce  the  simplest  version  of  a  Hierarchical  Multi-State  (HMS)  machine. 

Definition  4  (Basic  HMS  Machine):  A  “basic  HMS  machine”  is  a  triple  H  =  (S,  Pd,  Fn), 
where  S  is  a  set  of  states,  and  To  and  Tjm  are  (possibly  empty)  sets  of  transitions  over  S.  Pd 
and  Pn  will  be  called  the  “deterministic”  and  “nondeterministic”  transitions  of  H,  respec¬ 
tively.  When  there  is  no  confusion,  a  basic  HMS  machine  will  simply  be  called  an  “HMS 
machine.” 

Figure  2.1  presents  our  graphic  notation  for  representing  HMS  machines.  As  indicated  by 
the  legend  in  the  figure,  boxes  denote  states,  dark  arrows  show  transitions,  and  thin  arrows 
represent  controls,  with  VLSI  notation  defining  logical  operations  on  controls. 
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H  =  (S,  Fd,  Fn),  where 
S  =  {A,  B,  C,  D} 

Fd  =  {(3},  3  :  (A,  B)  ((B,  [-1,  0]))  ->  (D) 
Fn=  {a},  a  :  (A)  ((.D,  <-5.-2>))  — >  (C) 


Legend 

State 


Transition 

Non-Determinism 

Control 


[>  Not 


© 


Time  Delay 
3t,  ti  <  t  <  t2 


[tl.tzl  Vt,  ti  <  t  <  t2 


Figure  2.1.  Graphic  Notation  for  HMS  Machine 


We  now  turn  to  the  definition  of  the  “execution”  of  an  HMS  machine.  Informally,  a  ma¬ 
chine  executes  by  “firing”  some  of  its  transitions  at  each  moment,  thereby  altering  the 
values  or  “markings”  of  some  or  all  of  its  states  at  the  next  moment.  A  generalized  concept 
of  marking  will  now  be  introduced  that  allows  the  representation  of  the  history  of  an  HMS 
machine  behavior  for  the  infinite  past.  The  assumption  of  an  infinite  past  will  simplify  later 
definitions,  but  only  finite  histories  are  needed  in  practice. 

Definition  5  fMarking):  M  is  a  “marking”  of  an  HMS  machine  H  =  (S,  Fd,  Fn)  if  M  is  a 
mapping  from  S  x  {0,  -1,  -2,  ...}  to  {T,  F}.  If  M(s.  i)  =  T  (F),  then  the  state  s  is  said  to  be 
“marked”  (“unmarked”)  or  “true”  (“false”)  at  time  i.  All  times  are  relative  to  the  current 
moment,  which  is  denoted  by  0. 

Given  an  HMS  machine,  at  any  moment  of  time,  some  of  its  transitions  are  “enabled.”  An 
HMS  machine  executes  by  “firing”  all  its  enabled  deterministic  transitions  and  a  subset 
(possibly  empty)  of  its  enabled  nondeterministic  transitions,  thereby  resulting  in  a  new 
marking  for  the  next  moment.  This  process  is  formalized  by  Definitions  6-10: 

Definition  6  fControl  Satisfaction!:  The  control  c  is  “satisfied”  by  a  marking  M  if 

(i)  c  is  (s,  <ti,  t2>)  and  M(s,  ts)  =  T  for  some  t3  s.t.  ti  <  t3  <  t2. 

(ii)  c  is  (s,  [ti,  t2])  and  M(s,  t3)  =  T  for  every  t3  s.t.  ti  <  t3  <  t2. 

(iii)  c  is  (s,  <ti,  t2>!),  M(s,  t3)  =  T  for  some  t3  s.t.  ti  <  t3  <  t2,  and  M(s.  ti  -  1)  =  F. 

(iv)  c  is  (->s.  <ti,  t2>)  and  M(s,  t3)  =  F  for  some  t3  s.t.  ti  <  t3  <  t2. 

(v)  c  is  f--s,  [ti,  t2l)  and  M(s,  t3)  =  F  for  every  13  s.t.  ti  <  t3  <  t2. 

(vi)  c  is  (--s,  <ti,  t2>!),  M(s,  t3)  =  F  for  some  t3  s.t.  ti  <  13  <  t2,  and  M(s,  ti  -  1)  =  T. 

Given  a  set  of  controls  C,  we  write  M  1—  C,  if  every  member  of  C  is  satisfied  by  M. 
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Definition  7  TTransition  Enablement^:  The  transition  y  is  “enabled”  for  marking  M  if  (1) 
M(s,  0)  =  T  for  all  s  in  PRIMS (7),  and  (2)  c  is  satisfied  by  M  for  all  c  in  CTRLSCy). 

For  convenience,  we  define  the  following  sets  for  H  =  (S,  To,  Fn)  and  marking  M; 

D-ENAB(H,  M)  =  {7  1  7  e  Fd  and  7  enabled  for  M), 

N-ENAB(H,  M)  =  {7  1  7  G  Fn  and  7  enabled  for  M}. 

Definition  8  CFiring  Set):  The  set  of  transitions  F  is  a  “firing  set”  of  H  =  (S,  Fq,  Fn)  for 
marking  M  if  F  =  D-ENAB(H,  M)  u  F’,  where  F’  C  N-ENAB(H,  M). 

Definition  9  INext  Marking^:  If  M  is  a  marking  of  an  HMS  machine  H,  and  if  F  is  a  firing  set 
of  H  for  M,  then  the  marking  “after  M  via  F”  is  denoted  by  M[F],  and  is  given  by 
M[F](s,  0)  =  T  for  every  state  s  in  CNSOS(F) 

M[F](s,  0)  =  F  for  every  state  s  in  PRIMS(F)  but  not  in  CNSOS(F) 

M[F](s,  0)  =  M(s,  0)  for  every  state  s.not  in  either  PRIMS(F)  or  CNSQS(F) 

M[F](s,  t)  =  M(s,  t  +  1)  for  every  s  g  S,  and  every  time  t  <  0. 

Definition  10  fHMS  Execution') :  If  H  is  an  HMS  machine,  and  if  Mq  is  a  marking  of  H,  then 
an  “execution  of  H  from  Mq”  is  a  sequence  [Mq,  Mi,  M2,  ...]  of  markings  such  that 
Mj+i  =  Mi[Fi]  for  some  firing  set  Fi  of  H  for  Mj,  for  each  i  >  0. 

The  set  of  all  executions  of  H  from  Mq  is  denoted  by  0(H,  Mq).  Intuitively,  at  each  moment, 
all  the  enabled  deterministic  transitions  and  a  subset  of  the  enabled  nondeterministic  transi¬ 
tions  fire,  thereby  causing  changes  in  the  marking  of  H. 

An  HMS  machine  can  be  considered  as  a  “specification”  of  the  dynamic  behavior  of  a 
system.  For  example.  Figure  2.1  depicts  the  execution  of  a  simple  HMS  machine  with  four 
states  and  only  deterministic  transitions.  Initially,  only  the  state  A  is  marked  (denoted  by 
small  dark  circle).  In  the  subsequent  three  time  steps  certain  transitions  fire  causing  other 
states  to  be  marked  and  some  marked  states  to  be  unmarked.  For  example,  at  time  t+2.  the 
transition  o;  is  enabled  since  (1)  its  primary  state  A  is  marked  and  (2)  the  control  (B,  <-2, 
-1>)  is  satisfied  since  the  state  B  was  marked  at  time  (t+2)-l. 

The  “hierarchical”  version  of  HMS  machines  (the  “H”  in  HMS)  is  obtained  by  allowing  each 
state  to  be  an  HMS  machine  itself  and  designating  certain  states  as  “initial  states”  and  “final 
states.”  A  definition  of  this  was  presented  in  [Ga-88a],  along  with  a  discussion  of  the 
structural  constraints  and  execution  protocols  that  are  necessary  to  execute  such  machines.  In 
this  paper,  the  hierarchical  version  of  HMS  machines  will  not  be  considered.  Instead,  we 
turn  next  to  the  consideration  of  the  much  more  powerful  notion  of  higher-level  HMS  ma¬ 
chines  that  control  lower-level  HMS  machines. 
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Figure  2.2.  Example  of  an  HMS  Machine  Execution 


3.  Policy  Machines  and  Requirements 

An  HMS  machine  with  nondeterministic  transitions  can  be  considered  as  an  executable 
specification  of  the  generic  structure  of  a  software  system  that  satisfies  a  general  set  of 
requirements.  It  can  serve  as  a  reusable  specification  that  is  particularized  by  the  addition 
of  further  constraints.  In  [Ga-88a],  these  further  constraints  were  provided  as  a  set  of 
“policies”  of  the  form 

[priority]  precondition  — >  postcondition, 

where  each  precondition  and  postcondition  is  a  predicate  on  the  markings  of  states.  A  policy 
becomes  “active”  if  it  is  the  highest-priority  policy  for  which  its  precondition  is  true.  An 
active  policy  then  is  “triggered”  by  finding  a  path  through  the  nondeterministic  transitions  of 
the  associated  HMS  machine  that  makes  its  postcondition  true.  The  execution  of  the  HMS 
machine  along  this  path  then  causes  the  satisfaction  of  the  policy.  In  [Ga-88a],  an  example 
of  a  12-state  HMS  machine  with  six  policies  was  demonstrated  that  provides  a  complete 
specification  of  an  elevator  for  any  number  of  floors.  Without  the  use  of  policies,  the  speci¬ 
fication  would  have  been  considerably  more  complicated  since  it  would  have  been  necessary 
to  specify  the  desirable  paths  explicitly. 

A  more  powerful  means  of  particularizing  an  HMS  machine  with  nondeterministic  transi¬ 
tions  is  by  controlling  its  execution  with  other  HMS  machines.  We  introduce  a  new  type  of 
HMS  machine  that  can  define  the  requirements  (or  constraints)  on  the  execution  of  a  lower- 
level  machine.  An  ordered  list  of  machines,  with  the  lowest  one  being  a  basic  HMS  ma¬ 
chine.  will  then  constitute  a  multi-level  specification  of  a  software  system.  This  improves 
on  the  two-level  method  of  policies  in  three  important  respects:  (1)  specification  can  be 
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performed  at  arbitrary  number  of  levels;  (2)  a  uniform  language  can  be  used  for  specifica¬ 
tion  and  requirements  definition;  and  (3)  requirements  can  be  represented  graphically. 
Most  importantly,  both  basic  and  policy  nondeterministic  machines  can  function  as  reusable 
specifications  that  can  be  particularized  by  higher-level  machines. 

To  formalize  the  idea  of  a  policy  HMS  machine,  we  begin  by  introducing  a  new  type  of 
transition  that  can  be  used  to  define  requirements  for  a  lower-level  machine. 

Definition  11  ('Policy  Transition'):  8  is  a  “policy  transition”  over  the  set  of  states  S  if  8  is  of 
the  form 

id:  (PRIMARIES)  (B:  CONTROLSi,  M:  CONTROLS.,  E:  CONTROLS3)  — » 

(CONSEQL^NTS) 

where  (1)  id  is  a  “label.”  (2)  PRIMARIES  is  a  (possibly  empty)  subset  of  S,  (3)  CON¬ 
TROLSi,  CONTROLS2  and  CONTROLSsare  a  (possibly  empty)  sets  of  controls  over  S 
(respectively,  called  “beginning  controls,”  “middle  controls,”  and  “end  controls”),  and  (4) 
CONSEQUENTS  is  a  (possibly  empty)  subset  of  S.  The  five  sets  in  items  (2)-(4)  will  be 
denoted  PRIMS(8),  CTRLSb(8).  CTRLSm(8),  CTRLSe(8)  and  CNSQS(8). 

A  policy  HMS  machine,  with  respect  to  some  other  HMS  machine,  can  now  be  defined. 

Definition  12  fPolicv  Machine!:  Given  an  HMS  machine  H  =  (S,  Pd,  Pn),  we  say  that  a  triple 
H’  =  (S’,  Pd’,  Pn’)  is  a  “policy  machine”  for  H  if  S’  is  a  subset  of  S,  and  if  Pq'  and  Pn’  are 
(possibly  empty)  sets  of  policy  transitions  on  S’.  Pd’  and  Pn'  will  be  called  the  “determinis¬ 
tic”  and  “nondeterministic”  policy  transitions  of  H,  respectively. 

This  definition  applies  even  if  H  is  a  policy  machine  itself.  Then,  an  “n-level  (multi-level) 

HMS  specification”  of  a  system  is  obtained  by  defining  an  ordered  list  (H, .  Hn)  of 

machines  such  that  H|  is  a  basic  HMS  machine  and  each  Hj,  for  i=2.  ...,  n,  is  a  policy 
machine  for  Hj-i. 

We  now  turn  to  the  definition  of  the  execution  of  such  a  list  of  HMS  machines.  Intuitively,  a 
policy  transition  defines  the  desirable  behavior  of  the  next  lower-level  machine.  While 
transitions  in  a  basic  HMS  machine  are  instantaneous,  a  policy  transition  can  take  any  num¬ 
ber  of  time  steps.  A  policy  transition  can  begin  if  its  beginning  controls  are  satisfied  and  its 
primaries  are  true;  it  can  continue  if  its  middle  controls  are  satisfied:  it  can  complete  when 
the  consequents  are  true  one  moment  after  the  end  controls  were  true. 

Thus,  policy  transitions  direct  transitions  at  lower  levels  by  defining  the  goals  or  dynamic 
requirements.  The  achievement  of  a  goal  may  involve  numerous  lower-level  transitions  that 
will  have  to  be  found  by  a  search  of  the  nondeterministic  transitions  at  the  lower  level.  This 
search  can  be  automated  to  a  large  extent,  and  so  the  entire  n-level  specification  becomes 
highly  simplified  and  yet  is  itself  executable. 

We  now  introduce  definitions  leading  to  the  formalization  of  policy  machine  execution. 
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Definition  13  fPolicv  Transition  Enablement):  Let  H  be  a  policy  machine  with  marking  M. 
Then  a  policy  transition  8  of  H  is  “enabled”  if  (1)  M(s,  0)  =  T  for  all  s  in  PRIMS (5),  and  (2)  c 
is  satisfied  by  M  for  all  c  in  CNTRLb(8).  The  definitions  of  sets  D-ENAB(H,  M)  and 
N-ENAB(H,  M)  from  Section  2  extend  to  policy  transition  sets  in  a  straightforward  manner. 

Definition  14  fPolicy  Firing  SetL  Let  H  =  (S,  Fd,  Fn)  be  a  policy  machine.  Then  F  is  a 
“policy  firing  set”  of  H  from  M  if  F  =  D-ENAB(H,  M)  u  F’,  where  F’cN-ENAB(H,  M). 

A  policy  firing  set  determines  the  set  of  policy  transitions  that  begin  to  fire  (or  become 
active)  at  the  higher  level.  We  also  need  to  define  conditions  under  which  higher-level 
transitions  can  continue  and  the  conditions  under  which  they  can  terminate  (cease  to  be 
active). 

Definition  15  CPolicy  Transition  Continuation):  A  policy  transition  8  of  a  policy  machine  H 
can  “continue”  for  marking  M  if,  for  all  c  in  CTRLSm(S),  c  is  satisfied  by  the  marking  M. 

Definition  16  ('Policy  Transition  Termination):  A  policy  transition  8  can  “terminate”  for 
marking  M  if  M  f-  CNSQS(8)  and  M’  h-  CTRLSe(8),  where  M’(s.  i)  =  M(s,  i-1)  is  the 
marking  at  the  previous  moment  of  time. 

Using  the  definitions  of  transition  enablement,  continuation  and  termination,  we  can  for¬ 
malize  the  concept  of  a  consistent  execution  path,  or  “plan,”  for  any  HMS  me  chine.  We 
begin  with  the  syntactic  definitions  of  a  plan. 

Definition  17  (Plan  for  Basic  Machine):  For  a  basic  HMS  machine  H  and  initial  marking  Mo, 
p  =  [Fo,  Fi,  ...]  is  a  “plan  for  H  from  Mo”  if  p  is  a  sequence  of  sets  of  transitions  of  H.  The 
plan  p  is  “internally  consistent  from  Mq”  if  [Mo,  Mo[Fo],  (Mo[FoJ)[  Fi],  ...]  is  an  execution  of 
H  from  Mq.  A  finite  prefix  of  a  plan  is  called  a  “finite  plan,”  and  is  internally  consistent  if  it 
is  the  prefix  of  some  internally  consistent  plan. 

If  p  is  an  internally  consistent  plan  for  basic  machine  H  from  Mo,  then  [Mo,  MoiFo], 
(Mo[Fo])[  F]|,  ...]  is  called  the  “induced  execution  of  H  from  Mo  via  p.”  If  p  =  [Fq,  Fi,  ....  Fn] 
is  an  internally  consistent  finite  plan,  then  we  write  Mo[p]  for  the  marking  (((Mo[Fo|)[Fi]) 

...)[r.]. 

Definition  18  fPlan  for  Policy  Machine):  For  a  policy  machine  H.  p  =  [(Fq,  Co,  To),  (Fi,  e,. 
Ti),  ...  j  is  a  “plan  for  H”  if  p  is  a  sequence  of  triples  of  sets  of  policy  transitions  of  H.  The 
sets  Fi,  Cj  and  T \  are,  respectively,  the  “firing  set,”  “continuation  set”  and  “termination  set" 
of  p  at  time  i.  The  plan  p  “internally  consistent”  if  it  satisfies  five  conditions:  (1)  Co  and  To 
are  empty;  (2)  for  all  i.  Fi  and  Cjare  disjoint;  (3)  for  all  i.  Ti  C  Fi-i  +  Ci-i;  (4)  for  all  i.  ei=  Fi-i 
+  Ci-i  -  Ti;  and  (5)  for  all  i,  if  8  e  Fi  then  there  is  a  j  >  i  such  that  8  g  Tj.  A  finite  prefix  of  a 
plan  is  called  a  “finite  plan,”  and  a  finite  plan  is  internally  consistent  if  it  is  the  prefix  of 
some  internally  consistent  plan. 

The  five  conditions  of  internal  consistency  for  a  policy  machine  plan  have  intuitive  mean¬ 
ings:  (1)  at  the  start  of  the  plan,  no  transitions  are  already  active;  (2)  no  transition  can  fire 
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while  it  is  continuing;  (3)  a  transition  can  terminate  only  after  it  has  begun  firing;  (4)  all 
transitions  that  have  begun  firing  either  continue  or  terminate;  and  (5)  every  transition  that 
begins  firing  must  eventually  terminate. 

We  next  define  what  it  means  for  a  plan  to  be  “consistent.”  Intuitively,  a  plan  is  consistent 
with  a  sequence  of  markings  if  the  behavior  suggested  by  the  plan  is  compatible  with  the 
behavior  suggested  by  the  sequence  of  markings. 

Definition  19  (Consistency  of  Plan  for  Basic  Machine):  Let  p  =  [To,  fi,  ....  fn]  be  a  plan  for 
basic  machine  H,  and  let  E  =  [Mo,  Mi.  ...j  be  a  sequence  of  markings  of  the  states  of  H. 
Then  p  is  “consistent”  with  E  if  [Mo,  Mo[roj,  (Mo[ro])[  Ei],  ...]  =  E.  A  finite  plan  is  consis¬ 
tent  if  it  is  the  prefi.'’  of  a  consistent  plan. 

Definition  20  (Consistency  of  Plan  for  Policy  Machine):  Let  p  =  [(To,  Co,  To),  (Fi,  Ci.  Ti),  ...j 
be  a  plan  for  policy  machine  H,  and  let  E  =  [Mo,  '  L,  ...)  be  a  sequence  of  markings  of  the 
states  of  H.  Then  p  is  “consistent”  with  E  if,  for  all  i.  (1)  Fj  is  a  firing  set  of  H  from  Mj;  (2) 
every  transition  in  Cj  can  continue  from  Mj;  and  (3)  every  transition  in  T j  can  terminate  from 
M,  ' 

Only  one  more  concept,  that  of  an  “induced  execution  from  a  plan.”  is  needed  before  the 
execution  of  an  n-level  specification  can  be  given.  We  saw  in  Definition  17  that  if  a  plan 

[Fo,  Fi . F„]  for  a  basic  1-lMS  machine  is  internally  consistent  from  Mo.  then  it  induces  the 

sequence  of  markings  (Mo,  Mo[Fo|,  (Mo(Fo|)[  F]],  ...j.  The  same  is  true  for  a  plan  of  a 
policy  machine:  if  the  plan  is  internally  consistent,  then  it  induces  a  sequence  of  markings 
on  its  states  from  a  single  marking. 

Definition  21  flnduced  Execution  from  Policy  Plan):  Let  p  =  [(Fn,  Co.  To).  (F,.  e,.T,).  ...j  be 
a  plan  for  policy  machine  H.  and  let  Mo  be  a  marking  for  H.  Then  E  =  [Mo.  M],  ...]  is  the 
“induced  execution  of  H  from  Mo  via  p”  if.  for  every  i  >  0. 

(1)  Mi(s,  0)  =  T  for  every  state  in  CNSQS(Ti); 

(2)  Mi(s,  0)  =  F  for  every  state  in  PRIMSfL)  -  CNSOS(T,): 

(3)  M|(s,  0)  =  Mi-i(s,  0)  for  e\ery  state  in  neither  PRI.MSiFj)  nor  CN.SQS(T,):  and 

(4)  Mi(s,  j)  =  Mi-i(s,  j+l)  for  every  state,  and  for  everv  j  <  0. 

Notice  the  similarity  between  the  induced  execution  of  a  policy  machine  (Def.  21)  and  the 
execution  of  a  basic  HMS  machine  (Defs.  9-10).  The  execution  of  an  n-level  specification 
can  now  be  given.  For  this  definition,  we  assume  that  a  plan  [Fo,  F,.  ...j  for  a  basic  machine 
is  written  as  if  it  were  a  plan  for  a  policy  mcchine:  [(Fo.  {}.  {}),  (F i.  {},  Fo),  (F;,  {},  Fj),  ...j. 

Definition  22  (n-Level  Specification  Execution):  Let  %  =  (Hi . Hn)  be  an  n-level  specifi¬ 
cation  with  initial  marking  M.  Then  an  “execution  of  from  M”  is  a  list  (pi . Pn),  where 

Pi  =  [(rio,  Cio,  T io),  (Fii,  Cji,  T ii).  ...|  is  an  internally  consistent  plan  for  H,.  such  that  (1)  for 
all  i  >  1  and  all  j  <  i,  Pi  is  consistent  with  the  induced  e.xecution  of  H,  from  M  via  pj;  and  (2) 

for  all  i  <  n.  and  for  all  j  >  0,  PRIMS(Fjti,,)  C  PRIMS(Fij)  and  CNSQSlT ,m.i)  G  CNSQS(T ,j). 
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These  two  conditions  have  the  following  intuitive  meanings:  (1)  the  plan  e  t  every  level  meets 
the  requirements  imposed  by  all  higher  levels;  and  (2)  the  plan  at  every  level  is  implemented 
by  the  plan  at  the  next  lower  level. 

Notice  that  the  execution  of  an  n-level  specification  36  =  (Hi . Hn)  from  marking  Mq  can 

begin  with  a  plan  for  the  highest  machine  Hn,  which  needs  only  to  be  consistent  its  own 
level.  Then,  dropping  down  one  level,  a  plan  can  be  found  tor  Hn-i  which  is  consistent  at  its 
own  level,  and  which  is  a  consistent  implementation  of  the  first  plan.  Continuing  'n  this 
manner,  the  execution  can  be  found  one  level  at  a  time,  with  higher-level  plans  providing 
hints  for,  and  imposing  requirements  upon,  plans  at  lower-levels. 

As  an  illustration  of  concept  of  multi-level  HM3  specification,  consider  the  pair  (Hi,  H2)  in 
Figure  3.1,  together  with  the  initial  marking  Mo,  where  Mo(A,  0)  =  T,  Mo(s,  i)  =  F  otherwise. 

I - © - 1>° - f 


[-3.  0) 


z 


Figure  3.1.  Example  of  a  2-Level  HMS  Specification 


The  following  is  a  plan  P2  for  the  policy  machine  H:: 

P2:  [({a}.  {}-  {}),  ({}.  {a}.  {}).  (0.  W-  0),  (0.  {a}.  {})-  ({},  {},  {a}),  ({},  {},  {}).  ••■I- 

In  this  plan,  policy  transition  o:  fires  at  the  first  moment  and  terminates  four  moments  later. 
The  induced  execution  of  H2  from  Mo  via  p2  is  E  =  [Mo,  Mi,  M2,  M3,  M4.  M5,  ...],  where 

Mi(A,  -1)  =  T,  and  Mi(A,  i)  =  Mi(B,  i)  =  F  otherwise. 

M2(A.  -2)  =  T,  and  M2(A,  i)  =  M2(B,  i)  =  F  otherwise. 

M3(A.  -3)  =  T,  and  M3(A,  i)  =  M3(B,  i)  =  F  otherwise. 

M4(A,  -4)  =  T,  M4(B,  0)  =  T,  and  M4(A,  i)  =  M4(B,  i)  =  F  otherwise. 

M5(A,  -5)  =  T,  M5(B,  0)  =  M5(B.  -1)  =  T,  and  M5(A,  i)  =  M.cfB,  i)  =  F  otherwise,  etc. 

Notice  that  the  plan  p2  is  consistent  with  E  (by  Def.  20):  A  is  initially  marked  and  it  has  been 
unmarked  for  three  moments  when  a  completes.  Here  are  some  possible  plans  for  Hi: 
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Pi:  [{X},  {},{},{},  {y},  {  },  ...] 
P’l:  [{X}.  {},{},  {y},  {  },  ...] 

P”i:  [{  },  {  }.  W.  {  }.  •••] 


Although  all  three  of  these  plans  are  consistent  with  the  marking  Mo,  only  pi  is  consistent 
with  the  induced  execution  E.  In  this  case,  the  induced  execution  of  Hi  from  Mo  via  pi  is 
[Mo,  Mo[{x}],  Mo({x},  {  }],  ...],  and  Mo[{x}]  agrees  with  Mi  on  states  {A,  B},  Mo[{x},  {  }] 
agrees  with  M2  on  {A,  B},  and  so  forth. 

Thus,  (pi,  P2)  is  a  consistent  execution  of  n-level  specification  K  from  initial  marking  Mq. 

4.  Verification  of  Consistency  of  Multi-Level  HMS  Specifications 

We  now  address  a  restricted  method  of  verifying  that  a  multi-level  HMS  specification  %  = 
(Hi,  ...,  Hn),  together  with  initial  conditions,  is  consistent.  It  is  sufficient  to  demonstrate  that 
there  exists  an  execution  (Def.  22)  of  from  any  marking  Mq  satisfying  the  initial  condi¬ 
tions.  In  this  section,  we  present  a  method  for  verifying  that  such  an  execution  exists,  given 
a  partially  defined  and  possibly  misordered  plan  for  the  lowest-level  machine  Hi.  A  practi¬ 
cal  example  of  this  will  be  presented  in  the  next  section. 

The  application  of  the  verification  method  of  this  section  postulates  the  existence  of  a  “po¬ 
tential  plan”  for  accomplishing  higher-level  deterministic  transitions  that  define  require¬ 
ments.  A  potential  plan  is  a  sequence  of  concurrent  sets  of  transitions  at  the  lowest-level 
basic  HMS  machine  that  can  lead  to  the  satisfaction  of  the  requirement,  if  there  were  no 
constraints.  Our  method  can  then  determine  mechanically  w'hether  there  is  any  scheduling  of 
these  transitions  (involving  delays  and  possible  reorderings)  that  will  satisfy  the  constraints. 
In  addition,  since  the  method  is  constructive,  correct  schedules  can  be  derived  if  they  exist. 

It  is  useful  to  contrast  our  verification  technique,  which  addresses  “liveness"  issues,  witi, 
methods  that  address  "safety”  issues  [La-77].  A  plan  can  be  considered  as  a  possible 
means  of  achieving  a  liveness  property.  The  method  to  be  presented  in  this  section  deter¬ 
mines  whether  a  potential  plan  can  be  properly  scheduled  (proving  liveness),  but  is  not 
designed  to  discover  that  no  feasible  plan  exists  (disproving  liveness).  In  [Fr-89|,  we  pres¬ 
ent  a  safety  verification  method  which  establishes  the  unreachability  of  “safety  states”  using 
correctness-preserving  transformations  on  HMS  maclunes  (proving  safety),  but  is  not  de¬ 
signed  to  show  reachability  of  safety  states  (disproving  safety). 

The  restricted  form  of  the  verification  method  that  we  consider  is  the  following:  (1)  We 
assume  that  we  wish  to  determine  if  a  single  high-level  deterministic  policy  transition  in  an 
n-level  HMS  specification  is  achievable  at  the  lowest-level  basic  machine.  (2)  We  assume 
that  we  are  given  (or  we  can  discover)  a  potential  plan  (sequence  of  sets  of  transitions)  that 
contains  all  the  necessary  steps  for  reaching  the  goal.  Such  a  plan  can  often  be  derived  by 
ignoring  all  the  controls  and  by  attempting  to  go  from  the  primary  states  of  the  deterministic 
policy  transition  to  its  consequents.  (3)  We  wish  to  determine  if  there  is  a  feasible  schedule 
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for  firing  the  nondetermini  Stic  transitions  in  the  plan  that  will  achieve  the  consequents  of  the 
high-level.  (4)  If  there  are  such  schedules,  we  wish  to  identify  them. 

As  an  example,  suppose  that  we  have  a  potential  plan  {x,  y}  z  w  {x,  w)  y  ,  where  each  letter 
corresponds  to  a  nondeterministic  transition  and  concurrent  firings  are  indicated  in  braces. 
In  this  plan,  x  and  y  are  fired  in  the  first  moment,  then  z  is  fired,  then  w  is  fired,  an  so  on.  To 
find  a  feasible  schedule,  we  must  derive  the  correct  ordering  and  intermediate  delays  that 
will  make  the  plan  feasible.  This  can  be  expressed  parametrically  using  the  following  defini¬ 
tion,  where  4)  represents  the  empty  firing  set,  indicating  a  wait  (no  action). 

Definition  23  rVariable  Delay  Plan!:  Let  po  be  a  plan  for  a  basic  HMS  machine.  Then  p  is  a 
“variable  delay  plan”  for  po  if  p  is  obtained  from  po  by  the  inclusion  of  a  number  of  terms  of 
the  form  cj)",  where  the  exponent  indicates  the  number  of  steps  waited.  Each  is  called  a 
“variable  delay.” 

For  the  example  being  considered,  one  variable  delay  plan  is  4>'  {x,  y}  z  w  ())''  {x,  w}  <{)"  y. 
Interestingly,  it  turns  out  that  allowing  exponents  to  be  negative,  results  in  the  discovery  of 
reordering  of  the  steps  in  the  plan.  Our  goal  is  to  determine  mathematically  the  feasible 
solutions  to  such  exponents  that  will  make  the  variable  plan  feasible  or  to  determine  that  no 
such  solution  is  possible.  This  can  be  a  non-trivial  task  since  the  HMS  machines  may  have 
complex  logical  and  temporal  controls  on  transitions. 

Overview  of  Solution  Technique  for  Variable  Delay  Plans:  Given  a  variable  delay  plan  p 
and  an  initial  marking  Mo,  our  verification  techniques  involves  a  three-stage  process: 

A.  Apply  a  set  of  “postconditions  laws”  to  obtain  symbolic  facts  that  will  be  true 
after  each  step  of  of  the  plan  is  executed. 

B.  Apply  a  set  of  “precondition  laws”  that  determine  what  facts  must  be  true  before 
each  step  of  the  plan  can  be  executed. 

C.  Use  the  results  of  A  and  B  to  obtain  a  set  of  numerical  inequalities  In  terms  of  the 
variable  delays  of  p.  Either  demonstrate  that  the  system  of  inequalities  is  incon¬ 
sistent  or  obtain  a  solution  that  allows  the  replacement  of  variable  delays  in  p 
with  constant  delays. 

We  now  present  the  postcondition  and  precondition  laws  and  we  provide  a  sketch  of  how 
inequalities  for  solving  for  the  variable  delays  can  be  obtained.  Recalling  the  definitions  of 
Section  2,  M  1—  C  indicates  that  the  set  of  controls  C  (interpreted  as  the  conjunction  of  the 
individual  controls  in  C)  is  true  in  the  marking  M. 

A.  Postcondition  Laws.  The  following  four  types  of  postcondition  laws  determine  sym¬ 
bolically  what  facts  can  be  derived  as  the  plan  is  executed  (A  is  a  transition  set  in  p): 

INITIAL: 

If  M  I—  C  and  c  is  a  conjunct  of  C,  then  M  I-  c 
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FIRING: 

If  s  e  CNSQS(A),  then  M[A1  1-  (s,  [0,  0]) 

If  s  E  PRIMS(A)  and  s  ^  CNSOS(A),  then  M[A|  h-  (-s.  [0,  0]) 

DRIFT: 

If  M  I-  (x,  [a,  3]),  3  <  0,  then  M[<t)‘]  |-  (x,  [a  -  i,  3  -  ij) 

If  M  f-  (x,  [a,  3]),  3  <  0  then  M[A]  |-  (x,  [a  -  1,  3  -  1]) 

If  M  t-  (s,  [a,  0]),  s  £  PRIMS(A),  s  g  CNSQS(A),  then  M[A]  h-  (s,  [a  -  1,  -  Ij) 
If  M  K  (-S,  K  01),  and  s  e  CNSQS(A),  then  M[A]  |-  fs.  fa  -  1.  -  Ij) 

STRETCH: 

If  M  1-  (x,  [a,  0]),  then  M[4)‘]  I-  (x,  [a  -  i,  0]) 

If  M  h-  (x,  [a,  0]),  and  x  g  PRIMS(A)  u  CNSQS(A).  then  M[A]  h-  (x.  [a-1,  0]) 

B.  Precondition  Laws.  The  following  four  types  of  precondition  laws  determine  symboli¬ 
cally  what  facts  need  to  be  true  as  the  plan  is  executed  (A  is  a  transition  set  in  p): 

FINAL: 

If  M  1-  C  needs  to  be  true  at  the  end  of  p  and  c  is  a  conjunct  of  C,  then  M[p]  I—  c. 
PRIMARY: 

If  p  =  pi  A  p2,  and  s  g  PRTMSfA),  then  M[pi]  t-  (s.  [0.  0]) 

CONTROL: 

If  p  =  Pi  A  p2,  and  c  e  CTRLS(A),  then  Mfpi]  h-  c 
UPPER: 

If  p  =  Pi  p2,  c  G  BEGIN-CTRLS(A),  jp]|  =  n,  and  A  g  Tp,  then  Mfpi]  I—  c 

P  =  Pi  P2.  c  G  MID-CTRLS(A),  !p,|  =  n,  and  A  g  Cn,  then  M[p,]  h-  c 

If  p  =  Pi  p2,  c  G  END-CTRLS(A),  |pi|  =  n.  and  A  g  Tp+i,  then  Mfpi]  1—  c 

C.  Derivation  and  Solution  of  Inequalities:  After  the  application  of  steps  A  and  B.  for 

each  initial  subplan  of  p’.  we  compare  the  facts  M|p’|  I-  Ci  derived  from  A  to  the 
necessary  facts  Mfp’f  (-  C2  derived  from  B.  Then,  for  each  control  (x.  t)  in  C;,  where 
X  is  s  or  -.s.  there  must  exist  an  (x,  t)  in  Ci  such  that 

0  If  t'  =  fa',  3’I  and  t  =  fa.  31-  then  fa.  31  Q  (a'.  31-  resulting  in  the  inequalities 

a  >  a',  3  <  3’- 

0  If  t’  =  <a',  3’>  and  t  =  fa,  31.  then  <a’,  3’>  £  fee.  31.  resulting  in  the  inequalities 
3  >  a'  >  a  or  3  >  3’  ^ 

fNote;  We  assume  that  no  fact  uses  a  sometime-change-delay,  since  any  control  of  the 
form  (x,  <a.  3>!)  can  be  replaced  bv  the  conjunction  of  (-.x.  a-1)  and  (\.  <a.  3>).] 
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If,  for  some  (x,  t’)  in  C2,  no  control  in  Ci  is  of  the  form  (x,  t),  then  the  original  plan  is 
inadequate.  The  set  of  all  inequalities  can  be  solved  using  standard  mathematical 
techniques  to  obtain  the  exact  values  of  delays  in  the  plan  p  that  can  realize  the  desired 
policy  transition  at  a  higher-level  policy  HMS  machine.  On  the  other  hand,  if  there  are 
no  solutions,  it  again  follows  that  the  original  plan  was  inadequate. 

As  indicated  earlier,  by  allowing  exponents  in  the  solution  to  the  system  of  inequalities  to  be 
negative,  reordering  of  the  sets  of  transitions  can  be  obtained.  A  negative  exponent  causes 
the  remainder  of  the  plan  to  be  shifted  back  in  time  by  the  magnitude  of  the  delay. 

This  completes  the  sketch  of  our  restricted  method  for  verifying  that  an  n-level  specification 
is  consistent.  To  review,  this  method  determines  a  scheduling  and  reordering  of  a  potential 
plan  that  can  satisfy  a  set  of  high-level  requirements  in  an  n-level  specification. 

5.  Example:  Engine  Monitoring  System 

In  this  section,  we  will  illustrate  the  multi-level  specification  and  verification  concepts  of 
this  paper  on  a  realistic  example.  Consider  an  embedded  software  system  that  monitors  a 
steam  generator  for  a  pressurized  water  reactor  (PWR).  Temperature  and  pressure  are 
independently  and  periodically  sensed,  numerically  calculated  from  sensor  readings,  and 
printed.  When  both  temperature  and  pressure  are  known  the  volume  can  be  numerically 
derived  and  printed.  The  sensor  control,  numerical  calculations  and  printer  control  are 
handled  by  software  modules  for  which  lower  timing  bounds  are  given.  The  HMS  machine 
Hi  of  Figure  5.1  provides  a  specification  of  this  system,  where  a  vertical  bar  represents  the 
empty  primary  set  for  a  transition.  Recall  that  an  asterisk  next  to  a  transition  arrow  indi¬ 
cates  nondeterminism.  Thus,  Hi  may  be  considered  as  a  generic  specification  of  a  whole 
class  of  PWR  systems,  with  the  specific  behavior  left  undetermined  while  the  possible  choice 
of  actions  is  specified  precisely. 

We  can  add  requirements  to  Hi  by  controlling  its  execution  with  the  policy  machine  H2  of 
Figure  5.2.  In  addition  to  providing  hints  about  the  overall  flow  of  activity  at  the  lower  level, 
H2  imposes  three  types  of  restrictions  on  the  monitoring  system:  (1)  temperature  cannot  be 
printed  while  or  soon  after  pressure  is  printed,  and  vice  versa;  (2)  the  calculation  of  volume 
should  not  be  undertaken  while  either  of  the  two  normal  sensing  cycles  is  underway;  and  (3) 
the  calculation  of  volume  should  only  be  undertaken  if  it  is  based  on  recent  temperature  and 
pressure  readings.  Note  that  all  the  policy  transitions  in  H2  are  nondeterministic. 
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Figure  5.1.  PWR  Steam  Generator  Monitoring  System:  Low-Level  Specification  Hi 
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Figure  5.2.  PWR  Steam  Generator  Monitoring  System:  Lower  Requirements  H2 


There  is  yet  another  level  of  requirements  for  this  monitoring  system,  which  can  be  specified 
by  a  policy  machine  H3.  This  machine  controls  the  policy  machine  H2,  imposing  three 
additional  requirements  on  the  system;  (1)  there  is  a  fixed  time  interval  between  tempera¬ 
ture  readings;  (2)  there  is  a  fixed  time  interval  between  pressure  readings;  and  (3)  there  is  a 
fixed  deadline  by  which  the  volume  must  be  written. 

Notice  that  all  the  transitions  in  H3  are  deterministic.  Thus,  the  execution  of  the  3-level 
specification  (Hj,  H2,  H3)  requires  that  all  transitions  in  H3  be  fired  whenever  they  are 
enabled.  This  can  be  achieved  at  the  lower  levels  only  if  there  is  an  infinite  plan  such  that 
(1)  Temperature  Sensor  Read  is  entered  every  22  moments;  (2)  Pressure  Sensor  Read  is 
entered  every  25  moments;  and  (3)  Volume  Written  is  entered  at  most  50  moments  after 


Sensor  System  On  first  becomes  true.  The  specification  is  inconsistent  if  there  is  no  such 
infinite  plan. 


To  illustrate  the  proof  method  described  in  Section  4,  we  will  demonstrate  a  claim  which  is  a 
part  of  the  overall  consistency  requirement;  there  is  a  finite  plan  p  such  that  (1)  Tempera¬ 
ture  Sensor  Read  is  entered  every  22  moments,  and  no  more  than  22  moments  separate  the 
last  entrance  from  the  end  of  the  finite  plan;  (2)  Pressure  Sensor  Read  is  entered  every  25 
moments,  and  no  more  than  25  moments  separate  the  last  entrance  from  the  end  of  the  finite 
plan;  and  (3)  Volume  Written  is  entered  at  most  50  moments  after  Sensor  System  On  first 
becomes  true. 

We  begin  with  a  formal  presentation  of  the  initial  marking  M  and  the  requirements  on  the 
final  marking  M[p]  after  the  plan  p  is  executed: 

M  I-  (Off,  [-00,  0])  (^On,  [-00,  0])  (nTSS,  [-oo,  0))  (-TSR,  [-oo,  0])  ...  (.VW,  [-oo.  0]) 
M[p]  I-  (TSS,  0)  (PSS,  0)  (VW,  -1)  (TSR,  <-22,  0>!)  (PSR,  <-25,  0>!) 

If  a  finite  plan  p  can  be  found  that  satisfies  these  requirements,  then  the  claim  will  have  been 
constructively  demonstrated. 

We  first  guess  that  the  volume  can  be  calculated  and  written  after  one  loop  around  each  of 
the  pressure  and  temperature  cycles.  Next,  we  guess  an  ordering  of  these  loops  to  get  the 
following  finite  plan  p’; 

3s  {3ti  3p}  Xj  yx  Xp  Zj  yp  Zp  Wx  Wp  Xx  -Xp  av  bv  Cv 

We  are  not  concerned  about  possible  misorderings  of  actions  in  this  plan,  since  the  proof 
method  can  discover  and  correct  such  errors.  We  also  note  that  the  policy  machine  H:  can 
be  used  as  an  intermediate  step  in  the  construction  of  a  candidate  plan.  In  this  case,  a  plan 
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which  visits  the  states  Temperature  Written  and  Pressure  Written  once  each  can  be  guessed 
at  this  level,  and  the  plan  p’  can  then  be  guessed  as  a  solution  to  this  intermediate  plan. 


Next,  we  extend  p’  into  a  variable  delay  finite  plan  p  by  interleaving  variable  pauses  between 
actions.  For  simplicity,  we  omit  pauses  at  the  start  and  end  of  p’,  since  these  are  known  to 
be  unnecessary; 

p  =  as  <j)“  {ax,  ap}  \r  4)'^  yx  4>‘''  Xp  zx  <1>‘^  yp 

zp  <j)‘®  wx  wp  xx  4)'**  Xp  4>'’^  av  4>‘'^  bv  4>'*'*  Cv. 

The  three  steps  of  the  proof  method  are  now  sketched  for  this  example. 

A.  Generate  postconditions  of  all  prefixes  of  p,  using  the  postcondition  laws.  Only  a  few 
of  these  facts  are  shown  below: 

M  t—  (-iOn,  [-00,  0])  by  Initial  Law 

M[as]  I—  (-'On,  [-cx5,  -1])  (On,  0)  by  Drift  Law,  Primary  Law 
M[as4>‘']  1“  (•’On,  [-00,  -il-1])  (On,  [-il,  0))  by  Drift  Law,  Stretch  Law. 

M[as4>‘'  {ax,  ap}  4)‘' xx  4>‘' yx]  h-  (PSR,  [-i3-i2-2,  0]) 

M[as4>“  (ax.  ap}  4>‘^  xx  4>‘^  yx  4>‘'‘]  F-  (PSR,  [-14-13-12-2,  0])  by  Drift  Law. 

M[as4>‘'  (ax,  ap}  ...  Xp]  l-  (TSR,  [-ill-il0-i9-3,  -ill-2]) 

]M[as4>“  {ax,  ap} ...  4)“'xp4)“2]  1-  (TSR,  [-112-111-110-19-3,  -112-111-2])  by  Drift  Law 

B.  Generate  preconditions  of  all  prefixes  of  p  that  end  with  a  variable  pause.  Only  a  few 
of  these  facts  are  shown  below: 

^I[as  4»‘‘  {ar,  ap}  4>*^  xx  4>*^  J't  4^'^]  1“  (PSR,  [-4,  0])  by  Control  Law 
M[as  4>“  {ax,  ap}  ...  4>‘“  xp  4>‘‘^]  h-  (TSR,  <-3,  0>)  by  Upper  Law 
M[as45‘’  {ax.  ap}  4>‘^ Cv]  f-  (TSS,  0)  ...  (PSR.  <-25,  0>!)  by  Final  Law 

C.  Derive  constraints  and  associated  inequalities  using  the  results  of  the  previous  two 
steps.  For  example,  from  the  four  boldfaced  facts  above  we  can  derive  the  following: 

[-4.  0]  C  [-i4-i3-i2-2.  0]  implies  i4  +  i3  +  i2  +  1  >  4 

<-3.  0>  e  [-il2-il l-il0-i9-3,  -il2-ill-2j  implies  il2  +  ill  +  2  <  3. 

The  full  set  of  inequalities  is  as  follows: 

il  =  3  i2  >  2  i3  >  3  i4  +  i3  +  i2  +  1  >  4  i5  +  i4  +  1  >  5 

i6  +  i5  +  1  >  7  i6  >  2  i7  >  5  ilO  +  i9  +  1  >  2  ill  +  ilO  +  1  >  4 
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i8  +  i7  +  i6  +  i5  +  14  +  i3  +  i2  +  6  =  22  19  +  18  +  17  +  16  +  15  +  14  +  13  +  12  +  6  =  25 

112  +  111  +  2  <  3  112  +  1  <  4  112  +  111  1  >  2  112  >  3  113  >  4 

114  >  3  114  +  113  +  112  +  111  +  4  <  22  114  +  113  +  112  +  3  <  25 

114  +  113  +  112  +  111  +  110  +  19  +  7  >  23  114  +  113  +  112  +  111  +  110  +  6  >  26. 

This  set  of  Inequalities  has  the  following  solution; 

11  =  3  12  =  2  13  =  3  14  =  0  15  =  4  16  =  2  17  =  5 

18  =  0  19  =  3  110  =  5  111  =  -2  112  =  3  113  =  4  114  =  3. 

From  these  values,  we  obtain  the  following  finite  plan: 

as  <|>^  {ax,  ap}  4>^  xj  yj  xp  (t*"*  4^^  yp  zp  wj  (j>^  wp  4)^  xx  xp  cj)^  av  4''’  bv  4*^  Cv 

The  elimination  of  the  one  underlined  delay  with  a  negative  exponent  is  achieved  by  shifting 
back  the  subplan  after  the  “4)'^”  term  by  two  steps  and  recombining  terms: 

as  4>^  {ax,  ap}  4^^  xx  4>^  yx  xp  zy  4>^  yp  4>^  zp  wx  4>^  wp  4»^  Xx  4>‘^  xp  4'^  av  4>'’  bv  4>^  Cv  = 

as  4>^  (ax,  ap}  4>^  xx  4>^  yx  xp  4*'^  zx  4>^  yp  4*^  zp  wx  4>^  wp  4*^^  4>  ^x 

Xp  4*  4**”  4^^  bv  4^^  Cv  = 

as  4>^  (ax,  ap}  4>^  4>^  yx  Xp  4>‘*  zx  4>^  yp  4>'  zp  wx  4>^  Wp  4>'*  Xp  Xx  4>^  av  4*'*  bv  4>^  Cv 

This  plan  for  the  lowest-level  machine  begins  by  turning  on  the  system  (as),  and  then  waits 
three  moments  (4)^),  starts  reading  both  temperature  and  pressure  ({ax,  ap}),  waits  two 
moments  (4>^),  starts  calculating  temperature  (xx),  waits  three  moments  (4>^),  starts  writing 
temperature  (yx),  starts  calculating  pressure  (xp),  waits  four  moments  (4>'^),  and  so  forth. 

Notice  that  two  other  solutions  to  the  inequalities  above  can  be  found  by  varying  only  the 
values  of  14  and  15:  (a)  14  =  -1  and  15  =  5,  or  (b)  14  =  -2  and  15  =  6.  These  solutions  would 
further  reorder  the  original  plan  by  (a)  making  the  first  temperature  w  rite  and  first  pressure 
calculation  simultaneous,  or  (b)  making  the  first  pressure  calculation  immediately  precede 
the  first  temperature  write. 

6.  Summary 

In  this  paper,  a  new  approach  was  introduced  for  multi-level  specification  of  real-time 
software  in  terms  of  HMS  abstract  machines.  The  major  benefits  of  the  approach  are  (1) 
significant  reduction  in  complexity  of  specifications  since  lower-level  details  can  be  ignored 
as  requirements  are  defined,  and  (2)  reusability  of  nondeterministic  specifications  through 
the  use  of  higher-level  policy  machines  that  impose  requirements  on  them.  In  addition,  a 
restricted  method  of  verifying  the  consistency  of  multi-level  specifications  was  presented. 
Because  of  the  constructive  nature  of  this  method,  given  the  set  of  tasks  necessary  to  satisfy  a 
requirement,  the  correct  ordering  and  intertask  delays  can  be  derived  algorithmically.  The 
utility  of  the  verification  method  was  demonstrated  for  a  three-level  specification  of  an 
embedded  software  system  by  deriving  a  task  execution  schedule  that  satisfies  a  set  of 
high-level  requirements. 
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